1. Field of the Invention
This invention relates to communication protocols in a computer system, and more particularly, to a method of communication between a device driver and a kernel in a computer system.
2. Description of the Related Art
Most operating systems, and particularly the UNIX operating system, are capable of supporting several different system architectures, and can interface with many different types of input/output (I/O) cards and peripherals. Generally, each such device is connected to the system via a hardware controller, and also has a software program called a "device driver". The core of the operating system software, or the "kernel", uses these device drivers to program the hardware controllers to facilitate input and output with the devices. In most systems, several devices may share the same controller and/or device driver.
In UNIX implementations, each driver is uniquely identified by a "major" number, and each device controlled by that driver is uniquely identified by a "minor" number. In this way, the kernel can feed an I/O request to the appropriate driver by checking the major number associated with the request, and the driver can in turn feed the request to the appropriate device by checking the minor number. The major and minor numbers together refer to a particular device on a particular controller programmed by a particular device driver.
Conventionally, when the user adds a device and its associated controller, he or she links the object code of the device driver into the kernel, enabling the kernel to program the new controller (via the device driver) to communicate with the device.
In the past, the drivers have not provided the kernel with information regarding the capabilities and limitations of the attached devices. This has led to several detrimental effects including: 1) the kernel may ask a controller or device to perform a task which it is not capable of performing, resulting in data loss or a failed I/O request; 2) the kernel may not formulate an I/O task in the most optimal way for the controller or device, resulting in reduced I/O throughput; and/or 3) the kernel may not take advantage of special features of the controller or device, resulting in lower overall functionality.
Currently, device manufacturers use widely varying interface protocols, making it difficult for the kernel to obtain the information it needs. Furthermore, most conventional communication schemes provide only limited information to the kernel, preventing the kernel from using the device efficiently. Previous attempts at standardizing the interface protocols have been inadequate because they are not robust enough to supply full information about the devices, and do not have the capability of adding more information. Consequently, devices using these systems have had to go outside the standardized protocol in order to provide additional information to the kernel, thus obviating the benefits of the interface protocol.
Some examples of the limitations of such prior art schemes are:
1) In some systems, information about a device can only be obtained by the kernel using the major number of the device as a key. Consequently, when one driver is associated with several devices, the kernel is unable to obtain information specific to the individual devices, thus requiring the driver to report the least common denominator of all its devices. As a result, if some of the devices have a particular I/O capability while others do not, and one driver covers both types of devices, the kernel will not be able to take advantage of the particular I/O capability.
2) Some systems, such as that used by the Santa Cruz Operation, limit the amount of information that can be communicated to the kernel. The Santa Cruz Operation communicates only one aspect of disk controllers, namely a one-bit flag indicating whether the "scatter/gather" feature is supported by the device. Other parameters, such as how much data may be transferred with or without "scatter/gather", or whether the device has any memory access limitations, are not communicated to the kernel. In fact, since such parameters can only be communicated through integers, rather than single-bit flags, it is not possible to communicate them with the conventional scheme of operation. Rather, the kernel guesses at some of these limits and ignores others--a practice that may and sometimes does result in reduced performance, data corruption, or even system failure if the kernel's assumptions are incorrect.
3) Some systems improve on that of the Santa Cruz Operation, but are still fundamentally limited in that they use flags where numerical information is needed, and they provide no mechanism for adding more parameters than was initially contemplated.
Without a standard interface scheme which allows for communication of all relevant information between device drivers and the system kernel, including provisions for adding more information than was initially contemplated in the interface's design, the kernel must either be reprogrammed to deal with new communication protocols whenever peripherals are connected to the system, or it must make dangerous assumptions about the capabilities of the devices.